Tom,
Things are moving along nicely now, and things are behaving in a more predictable logical manner. I've long had a problem with this app where making some seemingly inane change will cause seemingly random hangs. Since fixing the BeginIvoke/Invoke problem, those seem to be gone, and the overall responsiveness seems much improved, which is really nice to see. But I'm a bit confused by something I'm seeing now. When I detect the board has gone away, I start periodically issuing a command, and looking for a valid response, as an indication that it has come back. I have two different versions of the test code (simplified, obviously...):
This one works:
try {
// See if board is alive
MainStatus = KMController.GetStatus(false);
// It's Alive!
KMState = KMStates.Connecting;
} catch {}
This one does not:
try {
// See if board is alive
String s = KMController.WriteLineReadLine("CheckDone 0");
s = s.Trim();
if (s.Equals("-1"))
// It's Alive!
KMState = KMStates.Connecting;
} catch {}
The way the second one fails is bizarre - it always connects correctly when the app is first started, properly detects when the board disconnects, properly detects when the board re-connects, *except* the initialization on re-connect never completes. Part of my init process is to run a G-code "init" program, by using Interpreter.Intperpret, then setting flag "InterpreterIsRunning", which is cleared by the InterpreterDone callback. When using the second block of code above, the InterpreterDone callback never happens, to the init process just hangs, with InterpreterIsRunning stuck true. If I comment out the wait on InterpreterIsRunning, then it re-connects every time. But, the init program is not being run. Change out *only* the above few lines of code, so I'm testing with GetStatus(), and it all works perfectly every time! Makes no sense to me. Can you think of any reason it would be behaving like that? My guess is this is merely a symptom of some other, more insidious, problem...
Also, should I be using GetStatus(true) or GetStatus(false)? The latter seems to create hangs....
Regards,
Ray L.
--- In DynoMotion@yahoogroups.com, "himykabibble" wrote:
>
> Success! It was, as expected, a bonehead error. I was using BeginInvoke, instead of Invoke. Under these conditions, that is basically an invitation to deadlock. Amazing how you can look at code and see what you *think* is there, rather than what's really there. Anyway it's now working, and gracefully handling connect/disconnect events, so I now have to re-enable all the other functionally back, and start cleaning things up. As an added bonus, the app starts up a lot faster as well.
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, "himykabibble" wrote:
> >
> > Tom/Brad,
> >
> > I think I'm making a little progress, albeit painfully slow. A couple things I'm not clear on.
> >
> > First, GetStatus(bool) - What exactly is the meaning of the bool argument? I was doing GetStatus(true), which appears to have been what was causing it to hang waiting for a lock. So what is the proper usage?
> >
> > I can now reliably detect connection and disconnection, and discovered all the annoying error dialogs were coming from my KMController_ErrorHandler. I forgot that was even there - that's the problem with only working on this stuff once a year.... Anyway, that is sorted out now. But, I've created a new problem, no doubt thread-related. When the board is disconnected, the GUI stops updating, and basically freezes. The code is still running, and updating the GUI elements, but they're not appearing on-screen. I can't for the life of me figure out why. As soon as the board is plugged in and available for use, everything comes back to life. I'm running only two threads - the GUI thread, and a worker thread that is checking the board connection state, and invoking a simple method in the GUI that updates the on-screen "Connected" indicator. That second thread spends most of it's time in a sleep(), waking up 10X/second to check the connection by doing a GetStatus().
> >
> > Any ideas where/how to look for the cause of this problem? I'm in over my head on this one.... But, I feel like I'm getting close! I think if I can get this issue resolved, I may be close to having this working again.
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com, "himykabibble" wrote:
> > >
> > > I've stripped most of the functionality out of my app, to get the connect/disconnect working properly, and I keep finding strange things. If I do a WriteLineReadLine("Version") with the board unplugged, the returned String consists of about 64 spaces. I was expecting an empty String. On startup, everything comes up properly, and when I pull the cable, the disconnect is detected correctly. At that point, I use a call to GetStatus to test whether the board has come back, and that seems to be throwing up a MessageBox to tell me it can't find a board, on each call. When I plug the board back it, it detects the board has come back, but then hangs - always ending up stuck in the DLL waiting for a TOKEN. I'm sure this is the result of something stupid I'm doing, but I don't know what, or how to pin it down.
> > >
> > > I am running just two threads, and the second one is doing an invoke to call the two dotNet functions it calls (GetStatus when the board is connected and initialized, and my CheckConnection() function when it is not connected.
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com, "himykabibble" wrote:
> > > >
> > > > Hmmmmm.... I implemented my test code is a simple app (hacked up the SimpleFormCS example), and it seem to work fine. So, I have to figure out why it doesn't work in my big app.
> > > >
> > > > --- In DynoMotion@yahoogroups.com, "himykabibble" wrote:
> > > > >
> > > > > Things were looking pretty good for a while last night, then it all went Pfffffttt! I've decided I need to bite the bullet and put in all the code to handle disconnects and reconnects gracefully. But it's fighting me tooth and nail at the moment.
> > > > >
> > > > > I've looked at the examples in 4.30j, but they appear to handle things in a way that would be very difficult to work with - any exception throws up a MessageBox with the exception error message. So, in a complex app, that means once the board is unplugged, you are bombarded with one MessageBox after another until the board is plugged back in.
> > > > >
> > > > > So, I tried to implement a mechanism that assumes life it good, goes about its business, and when a KMController call throws an exception, I then basically switch modes, and stop updating the main GUI, and instead start periodically running a simple function that just attempts to do something that requires communications with the board, waiting for that function to succeed. Once I detect the board was returned, I can then do my re-initialization (starting threads, restoring state, etc.), then, when it's ready, switch back to normal operation mode.
> > > > >
> > > > > Trouble is, a surprising number of functions seem return no error, and throw no exception, even when the board is not even plugged in! In particular, GetStatus() seems quite happy to be called all day, and never returns an error, never throws an exception. Several functions will throw up a MessageBox created by dotNet, so I don't dare call any of those those (don't ask me which ones they are, I don't know....), or I'm again flooded with MessageBoxes. So, I have to find a function that will consistently give an error or exception if the board is unplugged, consistently NOT give an error or exception when the board is plugged back in, and never throw up a MessageBox.
> > > > >
> > > > > I've tried to make use of CheckConnected, and it will reliably tell me when the board disconnects, providing I am making some other call to induce the error that makes it change state, but once the board is unplugged, I seem unable to get CheckConnected to ever return true again.
> > > > >
> > > > > So, how can I reliably detect that the board has re-connected, and is ready to go? And why do functions like GetStatus() not seem to return any kind of error even when the board is not connected?
> > > > >
> > > > > Regards,
> > > > > Ray L.
> > > > >
> > > >
> > >
> >
> |
|
